When a user wishes to open an instantaneous messaging session, a computer application placed in his mobile terminal sends a presence request intended for the messaging server. This presence request generally contains data making it possible to identify the user. Once the user has been identified by the messaging server, the latter sends to the other users that have opened a session, a piece of information indicating the presence of said user and his wish to converse. The computer application periodically sends the presence requests to the instantaneous messaging server according to a certain frequency.
When the user closes his messaging session, the computer application sends a disconnection request intended for the instantaneous messaging server. This disconnection request indicates to the messaging server that the user wishes to close his session and that he no longer wishes to converse with the other users. The messaging server then informs the other users of this event.
It may happen that a mobile terminal user cannot, or does not wish to, keep his instantaneous messaging session open constantly. This may be the case when the user is in a meeting, driving his car, etc. In such situations and with systems known in the art, either the user closes his session or he keeps it open but without conversing.
In the case where the user closes his session, the other users will be informed of this closing and they will stop conversing with him. This can be detrimental for the user, since he no longer receives any information at all until he opens a session again.
In the case where the user keeps his session open, he will no longer be able to converse with the other users. It can be unpleasant for the other users to not receive prompt replies from their correspondent, especially when the instantaneous messaging service is perceived as a means to be reach others in real time. This situation shows a first disadvantage with messaging systems known in the art.
In conventional instantaneous messaging systems, instantaneous messaging servers are able to deliver instantaneous messaging services to terminals connected to the servers, the users of which have opened an instantaneous messaging session.
Instantaneous messaging servers are in particular configured to detect a user connected to the instantaneous messaging service and inform the other users of his presence so that they may converse. These instantaneous messaging service servers are equipped with limited and very general features.
Other more complex services such as message filtering can be delivered by the messaging servers, but are not necessarily present in all messaging servers. If these services are not necessarily present, integrating such new services for use in a mobile terminal is a long and costly process for the operators, since a large number of initially provided management protocols and Software/Hardware must be modified. This is a second disadvantage found in known messaging systems of the art.
An instantaneous messaging system for mobile terminals known in the art is shown in FIG. 1. User A may have different contact lists, for example two in the instant case: a first list containing three contacts B1, C1, D1 members of a first instantaneous messaging service community Co1, for example YAHOO®; and a second list containing three other contacts B2, E2, F2 members of a second community Co2, for example MSN®. These contact lists are generally sent by the instantaneous messaging service servers S1, S2, to user A's mobile terminal TA. If user A wishes to converse with users B1, C1 and D1, he must connect to the instantaneous messaging server S1 associated with the first community Co1. If user A subsequently wishes to converse with users B2, C2 and D2 registered on the second community Co2, for example MSN®, he must disconnect from the first server S1 and connect to instantaneous messaging server S2 associated with this second community. This method is therefore laborious and sequential. In addition, there is no link between the different contact lists. For example, if user B is registered on several lists, it is not possible to have him appear one single time in a single list.
In order to efficiently manage a conversation via a instantaneous messaging service, it is simpler to converse only with a single portion of one's contacts and filter the messages from users with whom one does not to converse. Indeed, if all of the users converse at the same time, the conversation quickly becomes difficult to follow, all the more so when using a mobile terminal. To that end, user A can define filtering rules in such a way as to block messages intended for or sent by users with whom he does not wish to converse.
In the example shown in FIG. 1, concerning community Co1, user A wishes to converse only with user B1. Concerning community Co2, user A wishes to converse with users B2 and E2 and not with user F2. To that end, user A sends a request to server S1 intended to indicate that:                only messages coming from users B1, B2 and E2 can be communicated to him and/or messages sent by user A must only be intended for users B1, B2 and E2 (B1=OK; B2=OK; E2=OK);        messages coming from users C1, D1 and F2 must be blocked and/or messages sent by user A must not be sent to users C1, D1 and F2 (C1=NO; D1=NO; F2=NO).        
The filtering techniques are known by those skilled in the art. In principle, they involve filtering rules developed by the operators of instantaneous messaging service and integrated into their existing instantaneous messaging service servers. Currently, integrating filtering rules into instantaneous messaging service servers is a long and costly process for the operators, since a large number of management protocols and Software/Hardware must be modified. This reflects a third disadvantage present in known messaging systems of the art.
Another possibility that can be considered by those skilled in the art consists in integrating the filtering rules into the software of the mobile terminal which makes it possible to connect to the messaging servers. However, these filtering rules are known only by the software of the mobile terminal and the user will not retrieve these rules if he connects using another mobile terminal. In addition, this solution burdens the software of the mobile terminal since the data must be stored. This becomes a handicap in the case of mobile terminals having little or no storage and processing capacities.
In reference to the example in FIG. 1, the same user B can be a member of two different communities Co1 and Co2. In this case, he will have two different identities according to whether he is connected to one or the other community, for example B@Co1.com and B@Co2.com.
When user B opens an instantaneous messaging session on the first community Co1, he is seen by user A's mobile terminal as a first user B1 having, for example, B@Co1.com as identity. Likewise, when user B opens an instantaneous messaging session on a second community Co2, he is seen by user A's mobile terminal as a second user B2 having, for example B@Co2.com as identity.
In the instantaneous messaging service systems known in the art, in the case where user A wishes to establish a filtering rule for user B, two identical rules must be defined: one for user B1 and another for user B2. Regrettably, current systems do not allow user A to define a single filtering rule concerning user B and to apply this single rule to users B1 and B2. This is yet another disadvantage that affects messaging systems known in the art.
Thus, there remains a need to simplify the management of contact lists in an instantaneous messaging session in such a way that a user can easily converse with all of these contacts. In particular, there remains a need to simplify the implementation of the filtering rules in an instantaneous messaging system. There also remains a need to be able to add new instantaneous messaging services in a system known in the art, without having to modify the management protocols and/or Software/Hardware that is initially installed in the existing messaging servers. Furthermore, there remains a need to allow a user to easily continue an instantaneous messaging session when he cannot, or does not wish, to keep his session open. Finally, there remains a need to simplify the connection to the diverse instantaneous messaging service communities.